Workflow processes can be described as a sequence of steps/events resulting in an end solution or product. Some of the steps in the process may involve different parties who play specific roles or provide specific contributions. Each step in the workflow process is generally connected somehow with other steps involved in the process. Some steps may require that specific conditions be met or that other steps have previously been completed. One example of a workflow process includes an assembly line in a factory. In this model each component to the end product is designed to be added to the product at a pre-planned stage. Adding the component at an earlier step may just not make logical sense, or may even interfere with the addition of a later component. Therefore the addition of each component must be coordinated in a sequence of steps that is controlled and which does make sense.
Another everyday example of a workflow process includes making a loan application to a bank. The loan application is submitted to the loan officer and becomes a pending application. Next are a series of conditions which must be met as part of the loan approval process. The conditions include credit checks, income level and so forth compared with the requested loan amount. After initial conditions are met, the loan approval process still requires additional authorization from other parties, such as a loan manager. A loan can only reach an approved state after all of these workflow steps have been completed.
In the age of software, a workflow process can be run by a computer executing a program containing the rules, defined in computer code, for carrying out the steps in the workflow process. These software programs include finite state machines which execute the steps of a workflow process in their pre-planned order. In modern automation, organizational workflow process is classically implemented using computer forms, computer databases, and a multi-tier architecture with relevant computer code running in several locations. The problem with this current method is that the rules, or computer code, for performing the different steps in the workflow process are scattered in multiple locations. The workflow process is thus hindered by the need to locate the appropriate code for a given step and coordinate that computer code's execution with computer code for other steps located in still other places. Under the current system, complex processes requiring a large number of steps are difficult to implement. In some systems the computer code for a single workflow step may be spread among several locations. Therefore, an enormous degree of coherency is lacking. Data may be changed in one place without updating the data records held in another place. Thus different parties with access to the system may in fact see different snap shots of the workflow process in the same instance of time (instance is also a computer code term).
Permissions to execute changes to the data may similarly not be enforced to the extent intended in the workflow processes design. Thus, security and data integrity is usually not guaranteed. Additionally, the scattered nature of the workflow process computer code makes maintaining the system, or even updating the system to account for new parameters, more difficult and frustrating. And, to do so often requires costly, new application program interfaces (apis) and private extensions in order tie together clients, middle tiers of the workflow process, and end databases in the workflow process such as in servers.